Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update miniarm-rk3288_defconfig #18

Merged
merged 1 commit into from
Jul 31, 2018
Merged

Update miniarm-rk3288_defconfig #18

merged 1 commit into from
Jul 31, 2018

Conversation

Truv
Copy link
Contributor

@Truv Truv commented Jul 22, 2018 •
edited
Loading

Add iptables components configurations to distinguish traffic smoothly via ipset. It will be suitable for situation like this

@Truv
Update miniarm-rk3288_defconfig
3982049 
Add iptables components configurations to distinguish traffic smoothly via ipset. It will be suitable for  situation like this https://tinkerboarding.co.uk/forum/thread-1461.html
@jamess-huang
Copy link
Contributor

Excuse me, may I know why need this change ? I mean that from the link you provide, the author TkBd said that the issue was fixed on version 2.0.6.
https://tinkerboarding.co.uk/forum/thread-1461-post-6586.html#pid6586

@Truv
Copy link
Contributor Author

Truv commented Jul 25, 2018 •
edited
Loading

Hello,

Thank you for your reply.

I tried his way, but nothing could be changed until rebuilding kernel with the added modules mentioned as listed. Actually this issue is still exist even on version 2.0.7

I guess what he mean is the 'NAT' alone available on 2.0.6, actually, it's available at least on version 2.0.4. If you just use the basic NAT functions like to be set as a router, it will be totally Okay. But if you want make some further match such as using ipset or something else to match target much more precisely. The components listed above must be taken into account.

The error message: 'iptables: No chain/target/match by that name.' is not caused by NAT missing, but by the missing of modules which support the command '-m set --match-set aaa dst'. I used two versions of TinkerOS from 2.0.6 to 2.0.7. There is no doubt it's necessary.

Finally, let me illustrate the motivation. I want redirect the traffic to specific country to the specific port on my server. I imported the ip blocks of such a country to ipset and name it as 'aaa' so that iptables can match then by using '-m set --match-set aaa dst'. iptables will return error as 'No chain/target/match by that name.' if missing the modules above.

If those are still confuse you. I can set another usage as an example that is proxy gateway. Suppose you are in the US and we set tinkerboard as a gateway proxy, it can match the destination of every link, if the destination belongs to the US, then go directly. By contrast, if the destination towards overseas, put all traffic to listening port (often 1080) of the proxy server.

iptables -t nat -A PREROUTING -p tcp -m set  --match-set theUS dst -j RETUEN
iptables -t nat -A PREROUTING -p tcp -m set ! --match-set theUS dst -j REDIRECT --to-port 1080

Those two commands need those components.

Bests,

@jamess-huang
Copy link
Contributor

Hi,
Thanks for your detail explanation, we will check these kernel configs and feedback to you. Thank you.

@jamess-huang jamess-huang merged commit 7a9fb44 into TinkerBoard:develop Jul 31, 2018
@Truv Truv deleted the patch-1 branch August 1, 2018 10:06
Bauuuuu pushed a commit to Bauuuuu/debian_kernel that referenced this pull request Dec 5, 2018
@maurizio-lombardi @gregkh
cdrom: do not call check_disk_change() inside cdrom_open()
5e69983 
[ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ]

when mounting an ISO filesystem sometimes (very rarely)
the system hangs because of a race condition between two tasks.

PID: 6766   TASK: ffff88007b2a6dd0  CPU: 0   COMMAND: "mount"
 #0 [ffff880078447ae0] __schedule at ffffffff8168d605
 TinkerBoard#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49
 TinkerBoard#2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995
 TinkerBoard#3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef
 TinkerBoard#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod]
 TinkerBoard#5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50
 TinkerBoard#6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3
 TinkerBoard#7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs]
 TinkerBoard#8 [ffff880078447da8] mount_bdev at ffffffff81202570
 TinkerBoard#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs]
TinkerBoard#10 [ffff880078447e28] mount_fs at ffffffff81202d09
TinkerBoard#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f
TinkerBoard#12 [ffff880078447ea8] do_mount at ffffffff81220fee
TinkerBoard#13 [ffff880078447f28] sys_mount at ffffffff812218d6
TinkerBoard#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49
    RIP: 00007fd9ea914e9a  RSP: 00007ffd5d9bf648  RFLAGS: 00010246
    RAX: 00000000000000a5  RBX: ffffffff81698c49  RCX: 0000000000000010
    RDX: 00007fd9ec2bc210  RSI: 00007fd9ec2bc290  RDI: 00007fd9ec2bcf30
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000010
    R10: 00000000c0ed0001  R11: 0000000000000206  R12: 00007fd9ec2bc040
    R13: 00007fd9eb6b2380  R14: 00007fd9ec2bc210  R15: 00007fd9ec2bcf30
    ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b

This task was trying to mount the cdrom.  It allocated and configured a
super_block struct and owned the write-lock for the super_block->s_umount
rwsem. While exclusively owning the s_umount lock, it called
sr_block_ioctl and waited to acquire the global sr_mutex lock.

PID: 6785   TASK: ffff880078720fb0  CPU: 0   COMMAND: "systemd-udevd"
 #0 [ffff880078417898] __schedule at ffffffff8168d605
 TinkerBoard#1 [ffff880078417900] schedule at ffffffff8168dc59
 TinkerBoard#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605
 TinkerBoard#3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838
 TinkerBoard#4 [ffff8800784179d0] down_read at ffffffff8168cde0
 TinkerBoard#5 [ffff8800784179e8] get_super at ffffffff81201cc7
 TinkerBoard#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de
 TinkerBoard#7 [ffff880078417a40] flush_disk at ffffffff8123a94b
 TinkerBoard#8 [ffff880078417a88] check_disk_change at ffffffff8123ab50
 TinkerBoard#9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom]
TinkerBoard#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod]
TinkerBoard#11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86
TinkerBoard#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65
TinkerBoard#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b
TinkerBoard#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7
TinkerBoard#15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf
TinkerBoard#16 [ffff880078417d00] do_last at ffffffff8120d53d
TinkerBoard#17 [ffff880078417db0] path_openat at ffffffff8120e6b2
TinkerBoard#18 [ffff880078417e48] do_filp_open at ffffffff8121082b
TinkerBoard#19 [ffff880078417f18] do_sys_open at ffffffff811fdd33
TinkerBoard#20 [ffff880078417f70] sys_open at ffffffff811fde4e
TinkerBoard#21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49
    RIP: 00007f29438b0c20  RSP: 00007ffc76624b78  RFLAGS: 00010246
    RAX: 0000000000000002  RBX: ffffffff81698c49  RCX: 0000000000000000
    RDX: 00007f2944a5fa70  RSI: 00000000000a0800  RDI: 00007f2944a5fa70
    RBP: 00007f2944a5f540   R8: 0000000000000000   R9: 0000000000000020
    R10: 00007f2943614c40  R11: 0000000000000246  R12: ffffffff811fde4e
    R13: ffff880078417f78  R14: 000000000000000c  R15: 00007f2944a4b010
    ORIG_RAX: 0000000000000002  CS: 0033  SS: 002b

This task tried to open the cdrom device, the sr_block_open function
acquired the global sr_mutex lock. The call to check_disk_change()
then saw an event flag indicating a possible media change and tried
to flush any cached data for the device.
As part of the flush, it tried to acquire the super_block->s_umount
lock associated with the cdrom device.
This was the same super_block as created and locked by the previous task.

The first task acquires the s_umount lock and then the sr_mutex_lock;
the second task acquires the sr_mutex_lock and then the s_umount lock.

This patch fixes the issue by moving check_disk_change() out of
cdrom_open() and let the caller take care of it.

Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bauuuuu pushed a commit to Bauuuuu/debian_kernel that referenced this pull request Dec 7, 2018
@panicking @gregkh
brcmfmac: stop watchdog before detach and free everything
852f7cd 
[ Upstream commit 373c83a801f15b1e3d02d855fad89112bd4ccbe0 ]

Using built-in in kernel image without a firmware in filesystem
or in the kernel image can lead to a kernel NULL pointer deference.
Watchdog need to be stopped in brcmf_sdio_remove

The system is going down NOW!
[ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
Sent SIGTERM to all processes
[ 1348.121412] Mem abort info:
[ 1348.126962]   ESR = 0x96000004
[ 1348.130023]   Exception class = DABT (current EL), IL = 32 bits
[ 1348.135948]   SET = 0, FnV = 0
[ 1348.138997]   EA = 0, S1PTW = 0
[ 1348.142154] Data abort info:
[ 1348.145045]   ISV = 0, ISS = 0x00000004
[ 1348.148884]   CM = 0, WnR = 0
[ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[ 1348.158475] [00000000000002f8] pgd=0000000000000000
[ 1348.163364] Internal error: Oops: 96000004 [TinkerBoard#1] PREEMPT SMP
[ 1348.168927] Modules linked in: ipv6
[ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted 4.17.0-rc5-next-20180517 TinkerBoard#18
[ 1348.180757] Hardware name: Amarula A64-Relic (DT)
[ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20
[ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290
[ 1348.200253] sp : ffff00000b85be30
[ 1348.203561] x29: ffff00000b85be30 x28: 0000000000000000
[ 1348.208868] x27: ffff00000b6cb918 x26: ffff80003b990638
[ 1348.214176] x25: ffff0000087b1a20 x24: ffff80003b94f800
[ 1348.219483] x23: ffff000008e620c8 x22: ffff000008f0b660
[ 1348.224790] x21: ffff000008c6a858 x20: 00000000fffffe00
[ 1348.230097] x19: ffff80003b94f800 x18: 0000000000000001
[ 1348.235404] x17: 0000ffffab2e8a74 x16: ffff0000080d7de8
[ 1348.240711] x15: 0000000000000000 x14: 0000000000000400
[ 1348.246018] x13: 0000000000000400 x12: 0000000000000001
[ 1348.251324] x11: 00000000000002c4 x10: 0000000000000a10
[ 1348.256631] x9 : ffff00000b85bc40 x8 : ffff80003be11870
[ 1348.261937] x7 : ffff80003dfc7308 x6 : 000000078ff08b55
[ 1348.267243] x5 : 00000139e1058400 x4 : 0000000000000000
[ 1348.272550] x3 : dead000000000100 x2 : 958f2788d6618100
[ 1348.277856] x1 : 00000000fffffe00 x0 : 0000000000000000

Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bauuuuu pushed a commit to Bauuuuu/debian_kernel that referenced this pull request Dec 7, 2018
@panicking @ZhengShunQian
brcmfmac: stop watchdog before detach and free everything
17362ce 
[ Upstream commit 373c83a801f15b1e3d02d855fad89112bd4ccbe0 ]

Using built-in in kernel image without a firmware in filesystem
or in the kernel image can lead to a kernel NULL pointer deference.
Watchdog need to be stopped in brcmf_sdio_remove

The system is going down NOW!
[ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8
Sent SIGTERM to all processes
[ 1348.121412] Mem abort info:
[ 1348.126962]   ESR = 0x96000004
[ 1348.130023]   Exception class = DABT (current EL), IL = 32 bits
[ 1348.135948]   SET = 0, FnV = 0
[ 1348.138997]   EA = 0, S1PTW = 0
[ 1348.142154] Data abort info:
[ 1348.145045]   ISV = 0, ISS = 0x00000004
[ 1348.148884]   CM = 0, WnR = 0
[ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[ 1348.158475] [00000000000002f8] pgd=0000000000000000
[ 1348.163364] Internal error: Oops: 96000004 [TinkerBoard#1] PREEMPT SMP
[ 1348.168927] Modules linked in: ipv6
[ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted 4.17.0-rc5-next-20180517 TinkerBoard#18
[ 1348.180757] Hardware name: Amarula A64-Relic (DT)
[ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20
[ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290
[ 1348.200253] sp : ffff00000b85be30
[ 1348.203561] x29: ffff00000b85be30 x28: 0000000000000000
[ 1348.208868] x27: ffff00000b6cb918 x26: ffff80003b990638
[ 1348.214176] x25: ffff0000087b1a20 x24: ffff80003b94f800
[ 1348.219483] x23: ffff000008e620c8 x22: ffff000008f0b660
[ 1348.224790] x21: ffff000008c6a858 x20: 00000000fffffe00
[ 1348.230097] x19: ffff80003b94f800 x18: 0000000000000001
[ 1348.235404] x17: 0000ffffab2e8a74 x16: ffff0000080d7de8
[ 1348.240711] x15: 0000000000000000 x14: 0000000000000400
[ 1348.246018] x13: 0000000000000400 x12: 0000000000000001
[ 1348.251324] x11: 00000000000002c4 x10: 0000000000000a10
[ 1348.256631] x9 : ffff00000b85bc40 x8 : ffff80003be11870
[ 1348.261937] x7 : ffff80003dfc7308 x6 : 000000078ff08b55
[ 1348.267243] x5 : 00000139e1058400 x4 : 0000000000000000
[ 1348.272550] x3 : dead000000000100 x2 : 958f2788d6618100
[ 1348.277856] x1 : 00000000fffffe00 x0 : 0000000000000000

Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Truv @jamess-huang